The Open Mobile Alliance (OMA) sets out the XML Document Management (XDM) Architecture (see OMA XDM 2.0). This defines a common mechanism that makes user-specific service-related information accessible to the service enablers that need them. Such information is expected to be stored in the network where it can be located, accessed and manipulated (e.g. created, changed, deleted, etc.). XDM specifies how such information will be defined in well-structured XML documents, as well as the common protocol for access and manipulation of such XML documents.
Documents are accessed and manipulated via the common protocol XCAP, XML Configuration Access Protocol [see IETF RFC 4825 “The Extensible Markup Language (XML) Configuration Access protocol (XCAP)”, J. Rosenberg, May 2007, URL: http://www.ietf.org/rfc/rfc4825.txt]. XDM provides an architecture for managing service specific data and defines a common mechanism that makes user-specific service-related information accessible to the service enablers that need them. The service-s ecific information is expressed and exchanged by means of XML documents, and this information is stored in the network in logical repositories called XDMSs (XDM Servers). Each repository may be associated with a functional entity which uses its data to perform its functions. Each XML document stored in an XDMS is described as an XCAP Application Usage, which enables applications to use the document via XCAP.
FIG. 1 of the accompanying drawings illustrates some of the network entities defined in the above-referenced OMA Architecture Document. In FIG. 1, two XDM Clients 2-1 and 2-2 are in communication with respective different XDM Servers 6-1 and 6-2 via an Aggregation Proxy 4. The XDM Clients 2-1 and 2-2 are client entities that provide access to the various XDMS features. They provide an end user with the possibility to create, modify or delete an XML document, and by that create, modify or delete service specific data. The Aggregation Proxy 4 is the contact point for the XDM Clients 2-1 and 2-2 to access XML documents stored in any XDM Server; the Aggregation Proxy 4 performs functions like authentication or routing of requests. The XDM Servers 6-1 and 6-2 hold the service specific data, and implement the procedures to create, modify or delete such data.
The IP Multimedia Subsystem (IMS) is the technology defined by the Third Generation Partnership Project (3GPP) to provide IP Multimedia services over mobile communication networks. The IMS makes use of the Session Initiation Protocol (SIP) to set up and control calls or sessions between user terminals (or user terminals and application servers). The Session Description Protocol (SDP), carried by SIP signalling, is used to describe and negotiate the media components of the session. Whilst SIP was created as a user-to-user protocol, the IMS introduces additional functionality for e.g. subscription handling, security and charging to allow operators and service providers to control user access to services and to charge users accordingly.
FIG. 2 illustrates schematically how the IMS 22 fits into the mobile network architecture in the case of a GPRS/PS access network. Call/Session Control Functions (CSCFs) 24 operate as SIP proxies within an IMS core network 22a. A user accesses the IMS 22 via an access network and gateway nodes in a connectivity layer 26. A Home Subscriber Server HSS 28 keeps a log of users' subscription profiles that define the services that the user has subscribed to. After registering, the user is able to establish a communication session with other peers, making use of the multimedia capabilities of the IMS. The IMS also includes a service network 22b, in which Application Servers (ASs) 28 are provided for implementing IMS service functionality.
The 3GPP architecture defines three types of CSCFs: the Proxy CSCF (P-CSCF) which is the first point of contact for the user within the IMS core network 22a; the Serving CSCF (S-CSCF) controls the provision of services to the users in accordance with the user's subscription; and the Interrogating CSCF (I-CSCF) whose role is to identify the correct S-CSCF, based on the user's subscription profile which it obtains from the user's HSS 26, and to forward to that S-CSCF a request received from a SIP terminal via a P-CSCF.
FIG. 3 shows in more detail the XML Document Management Architecture as defined in the OMA-AD-XDM-V2_0-20090810-C document. The Aggregation Proxy 34 of FIG. 3 is the contact point for the XDM Client 2 to access XML documents stored in any XDMS. In this OMA-defined XDM solution it would be possible to fetch XML documents and search for information in XML documents in another operator's domain using an NNI (Network-to-Network Interface). The traffic to the remote network is routed via a Cross-Network Proxy entity 36a to the remote network. The protocol used is HTTP over some secure transport, such as for example TLS (Transport Layer Security). The requesting network requires some kind of service agreement with the remote network in order to be accepted by the remote network.
A Cross-Network Proxy 36b of the remote network of FIG. 3 is the contact point for a trusted network to access XML documents stored in any XDMS of the remote network. The NNI-I interface of FIG. 3 is between the Cross-Network Proxy 36a and the Cross-Network Proxy 36b of the remote network. The protocol for the NNI-1 interface is XCAP.
For normal SIP traffic, for instance when a user in an originating IMS network calls another user belonging to a different, remote IMS network, the SIP message is routed via the IMS Core of the originating network to an interconnection gateway node N-SBG (Network-Session Border Gateway). The N-SBG is responsible (among other things) for establishing a secure tunnel between the different networks. When the S-CSCF in the originating network has completed the originating services it will perform a DNS lookup of the domain address of the Request-URI in the SIP message and find the address of the I-CSCF of the remote network. The SIP message is then routed via the N-SBG to the remote side through the secure connection (normally IPSec).
For XCAP (HTTP) traffic as defined in OMA XDM 2.0 the procedure is quite different. If a user wants to access or retrieve an XML document (for example a picture) from another user in a different, remote network, the request is routed via the Aggregation Proxy (AP) to a Cross-Network Proxy (CNP), both in the originating network, and then to a CNP in the remote network. The CNP is defined as a HTTP Proxy (configured as a reversed proxy) and is responsible for checking that the remote network is a trusted network. The same procedure also applies when a request is received at the CNP in the remote network. OMA XDM 2.0 also states that the CNP is responsible for securing the data transfer CNP:s using TLS etc., but says no more about how this may be implemented.
Thus XCAP has its own way of defining the communication over the NNI and this has to be dealt with at two network locations (N-SBG and CNP). Also, as currently defined, the XCAP messages are sent between the networks over the NNI using a security mechanism that has to be established specially for HTTP/XCAP traffic. This makes the configuration of the system more complicated and introduces more potential sources for errors. Also, some networks, for example networks that operate over large geographic areas, are divided into regions or provinces each operating as a local or sub-network and use NNIs both between different operator networks, and also between their own regional sub-networks. Such a large number of NNIs, and the need to establish HTTP/XCAP security mechanisms for each places a severe burden on the system configuration.
Note, however, that XCAP messages are only one type of request to be handled and specified in the new OMA XDM 2.1 standard. Other HTTP-based OMA XDM requests include XDM Search requests and commands that use XML Document Command Protocol.
A method of simplifying the configuration of the CNP node is described in WO2009/068114. In this document it is suggested that the DNS is provisioned with the CNP XCAP root address of the remote network. However, the other problems referred to above remain.
It is therefore desirable to address these issues.